Drones

Summary

Overview
          Why a Drone?
Preparing Wad file
          One drone but two different items
          Sprites for Drone
Interaction between Lara and foldable drone
          Game commands for Drone
          Battery management
                    Two drones: full or empty
Preparing level map
          Why no pickup drones
          OCB codes for drone items
                    Drone OCB: 512
                    Drone OCB: 1024
                    OCBs for pickup Drone
Preparing Script commands
          Required script commands
                    Customize=CUST_DRONE command
                    Image= script command
                    Parameters=PARAM_SHOW_SPRITE command
                    Customize=CUST_TEXT_ON_FIXED_CAMERA command
                    Other commands
          Different Cam Views
                    When display telemetry and warning messages
          Drone strings management
                    Positional and numeric formatters
                    Two different telemetric data
          Proximity sensor or rebounding?
          Computation of signal strenght
                    Self Recovery of Safe position
                    Values of signal limits
          Taking little items: the magnet
          Engage TriggerGroups on Item Collisions
                    Example: to do explode static items
          Giving Drone the skill to engage directly triggers
                    How to avoid indiscriminate heavy trigger activations
Drone Triggers
          Triggers to forbid drone to visit some zones
          Change drone settings in game
                    Tips about changing dynamically flags
          Customize triggers
                    Change items for collision detection
          Trigger for variable managements
                    Fields of Real Drone
          Set temporarily max altitude
          Triggers to change VIEW_ flag dynamically
          Triggers for Drone cutscenes
                    To do drone following a path
                    Set the view type for the Cutscene
                    Start Follow-me feature
                              Settings for Follow-me trigger
                    Trigger to do perform a full rolling
                    Trigger to stop drone cutscene
          Triggers to change Drone management
                     Change current battery level
                    Display custom warning messages for drone
          Trigger to interfere in drone driving
                    Simulating an attack against drone
                    Diverting drone out of cutscenes
Global Triggers for Drone
          To do use GT globalTriggers or drone DRF_ flags to detect collisions?
Profiling section
          How to modify hardcoded settings of drone
          Hot to get a faster drone
          How to change game commands to move drone
The Drone Demo level
          Drone Cutscene
          Follow-me mode
          Killing Skeletons to get their key
          Catch a key with drone
          Destroy shatters with drone
          Open the door with push button for drone
                    The push button object
                    Advanced scripting for many doors/buttons
                    Simplified scripting to open a door with push button
          

Overview

This document is for level builders. It will be described as using the Drone object in the level you are going to build. There will be a description of required script commands and object to have in level wad.
There will be also a section to describe some trigger supported by plugin_demo.dll library but these are not really necessary to do work the drone but they are only an add-on to take adavantage of this object also for optional targets, like creating little cutscenes with drone as leading character.
You should learn not only how to do work the drone but also remind to explain this topic to players of your level.
Probably, since the "readme.txt" files had never been read so often, it could be better adding some short infos in game, with texts displayed when the player get the drone object or, better, creating a training level of your adventure (Lara's Home style), where the player could learn to drive it, helped by many instructions displayed, step by step in the training phase.

Why a Drone?

It could look weird inserting in a game as Tomb Raider a sort of flight simulator with a drone but we should consider some points:





Preparing Wad file



The foldable drone is a complex object, very different than all others seen in tomb raider adventures.
In above picture you see a list of items related to drone management.
There is the controller (A picture) used to drive the drone. In drone demo it is in PICKUP_ITEM1 slot.
The B picture shows the battery used by drone (PUZZLE_ITEM1 in Drone demo)
In C picture you see the folded (pikcup) drone (PICKUP_ITEM2 or PICKUP_ITEM3 in drone demo. See Battery management paragraph for more infos), while in D picture you see the (real, flying) drone with open arms, this is always in 506 DRONE slot.

Sprites for Drone



In your wad file you should copy also the CUSTOM_SPRITE object because drone (if you enable noise effect with DRF_NOISE_EFFECT_ON_NO_SIGNAL flag) requires some sprites.
First 3 sprites will work as animated sequence to simulate a disturbate frequence when drone is not reachable (for no signal or no battery), while the last sprite is to disply, over the noises screen, the "LOST DRONE" text. The usage of a sprite was necessary because common texts are not able to cover a sprite.


One drone but two different items

It's important understand that the C and D images show different items. Indeed the folded drone is not able to fly, it is a pickup and it could be handled in game only in two ways: stand on the ground, waiting to be picked up (and put in the bodybag), or in inventory, waiting to be selected to be placed on the ground.
When you project your level you should take care about above issue, since you should place only one foldable drone in your level and you'll have to choose the real drone, (from 506 SLOT Drone) .
Once you placed the real drone (that of D picture, with open arms), at begin of the level, the real drone will be converted in a pickup item (closing the arms and swapping the object to PICKUP_ITEM2 or PICKUP_ITEM3), but it's necessary that the real 506 DRONE object was present in the level map while the pickup item was missing. This is required for technical reasons.

Interaction with Drone items

In this table I'll try to summarize different interactions between Lara and the Drone's items, in according with current situation in game.
This table has been thought overall for players but it's important that you know how to handle it, of course.
Situation in Game Available Interactions
PICKUP ITEM ON THE GROUND

In this situation Lara/player, could act only in two ways:

1) click ACTION and pickup the drone to put it in Inventory
2) Enter in Inventory and select the controller. In this second case the pickup drone will become a real drone, opening its arms and Lara will start to drive it
In the case the controller was missing in inventory, it will be not possible engage the driving, of course and so, in this case, the player could only pickup the item or ignoring it.
DRONE IS FLOATING ON WATER

This situation is very alike than drone on the ground. Lara could picks up it, or (while she is on ground) take the controller and to do take off the drone from water.
How you can getting, the drone floats on water and so it is also able to land on water surface (or take off from it)
LARA IS GRABBING THE CONTROLLER

In this case the drone will be the real drone, with open arms. The real drone will be present only and always when lara is holding the controller, indeed, only when Lara takes the controller from inventory, the real drone will be operative.
DRONE IS FLYING

When the drone is flying, certainly Lara is grabbing the Contoller.
In this phase lara can driving the drone.
About the way to quit drone mode there are three chances:

- The player set to quit flying with [Inventory] (escape) command.

- Lara is under attack from some enemeies: the flying mode automatically quits, with Lara that puts off the controller and the drone that will have an emergency landing. Once on the ground, it will close its arms, becoming newly a pickup item that Lara could picks up.

- Lara is driving the drone but there is a signal of "low battery" or "low signal". When the drone is fully no more controllable, the drone will be "Lost". Lara will put off the controller and the drone will land (or fall down) becoming newly a pickup item.
CONTROLLER IN INVENTORY

Only possible action, in this case, is selecting the Controller but, in according with Drone state, this operation could work or less.

1) If also the drone is in inventory in that moment, the selection of Controller will not work, and the player will hear the classic "NO"
2) If the drone is missing in inventory, this means it is somewhere in the level, and in this case lara will hold the controller and the drone will open its arms getting operative.

Notes:
- There is the chance to forbid to control the drone when it is too far, setting a limited range of control. In this case, when the player tries to use the control but the drone is too far, there will be a signal on screen to inform of this failure (low signal, drone too far)

- From above rules we get the correct procedure is always to select, as first step, the drone from inventory (if it was there), and only then, to select the controller
DRONE IN INVENTORY

In this case it will be always possible selecting the drone, of course, and Lara will place it on the ground. Anyway, after this operation the drone is still a pickup, and only selecting also the Contoller will be possible to do fly it.
In the case the player had not the controller in inventory, then the selecting of drone will get only to place the pickup drone on the ground but without any chance to drive it. Probably, at that moment, the player will get to have to pickup newly the drone, to get it (newly) in inventory.
Remark:
if when player tries to select drone he receives a "NO" sound as reply, it means that Lara was trying to place drone on a bad surface.
It will be not possible placing the drone over unflat sectors, on water surface or over other items.
FULL DRONE IN INVENTORY

This item is practically the usual drone and you can use it as explaind above. The "(Full)" attribute is only to remind you that the drone is full, probably because it has been just equipped with a new battery or at begin of level.
Note: there is also a little difference between (Full) drone and common drone. The full drone has a green light led (on its back) while the common (not full) drone has a dark green led.
BATTERY IN INVENTORY

You can combine the battery with drone to get fully charged it, anyway, if the drone was already "full" the Combine menu will be not present.

When Lara will find the drone, at start, it will be always a pickup item with close arms. In this situation she could pick up it (to have it in inventory) or to do fly it.
To be able to do fly the drone is necessary that Lara took the Controller from inventory when drone is already on the ground. Trying to extract the controller before the drone was on the ground, will take to the well-known "No" sound.

In the case both items, drone and controller, were in inventory, the procedure will be: select drone (and Lara will place it on the ground) and then select the controller. Now the drone will open its arms and it will be ready, waiting command from controller.

Game commands for Drone



Above picture shows the commands to drive drone (you find it in "pixs" folder of drone demo, as "image1.bmp").
It's important that you (as level builder) remember to give your player the info about how to play with drone, since it is a new and very particular object.

Battery management

About batteries it's important remark that you can enable or less the battery management in Customize=CUST_DRONE script command.
I suggest to enable it, adding the DRF_USE_BATTERIES flag.
The reasons to enable battery usage are two:
- getting more realistic the drone experience (real drones have not unlimited power)
- adding a new target for players: looking for new batteries to do fly again the drone
Anyway, if you don't add the DRF_USE_BATTERIES flag, the drone will have unlimited energy and battery items will be no more required in game.

Two drones: full or empty



This could look like a complication but, to handle the combine between battery and drone, it has been necessary managing two different pickup drones.
In above picutre you can see that, other the name, there is also a little difference between them: the full drone has a light green led (on its tail) while the not full drone has a dark green led
When in inventory there are: one (or more) batteries and the not full drone, player will be able to combine the battery with this drone and it will get a (full) drone (and battery amount will be reduced by 1)

Preparing level map

In your level map you'll have to place:
- One (or more) controller
- Some batteries (one or more)
- One (and only one) real drone: the object in 506-DRONE
- No pickup drones

Why no pickup drones

The rule to do not place any pickup drones in the level map is because it will be plugin_drones code to swap between real (flying) drone (slot 506) and some of two pickup drones.
Once you placed a real drone in the level, when plugin_drones will load your level, it will create (dynamically) a pickup item in same position of real drone and then it will get invisible the real drone.
If you placed a pickup drone, then there will be two pickup drones and this fact could create troubles, since drone code is able to handle only one pickup drone at once.

OCB codes for drone items

Really only drone accepts ocb values, not the controller or battery.
There are two specific ocb codes for drone:

Drone OCB: 512

Set drone as "empty", i.e. with no battery or an "out of power" battery.
By default, omitting this ocb, the drone will be full at begin of the level but if you want that player had to look for a battery, before using drone, you can add 512 to drone's ocb

Drone OCB: 1024

The 1024 ocb works like a "reset hub" for drone.
You could use it when you are preparing the map of a further level (the drone was already present in previous level) and you want that drone data was rebuilt from scratch.
Since its target, it should be unnecessary set 1024 ocb in drone of first level: nothing could change but when you are working on following levels this is a chance.
Let's explain what is the default behaviour of plugin drone when you DON'T use 1024 ocb:
- In first level where there is a drone, the plugin will read the Customize=CUST_DRONE command, getting from it all required stuffs: used slots for controller, battery and pickup drones and many other settings
- When Lara jumps from a level (with drone) and the next, by default, all data about drone will be preserved: the current level of battery, the position of pickup drone (supposing it wasn't in inventory but on the ground) and all other drone's data. For this level, the plugin will NOT read the further Customize=CUST_DRONE of current level section and, for same reason, it's not necessary typing it in the script. (But, secondary script commands, like those for mask image, should be present, in new level section, with same id of previous level section)

Well, if you don't want above behaviour but you prefer that there was a new drone, with full battery and (let's say) different flags, images for mask or sprites for "lost drone" effect, you'll have to type in the drone of this new level the 1024 ocb (and probably you'll set in previous level also a ResetHub-= script comamnd with the index of this new level, to reset also drone pickup items in inventory)

OCBs for pickup Drone

Since you should NOT place a pickup drone in the level map, it could look weird to have the chance to set ocb codes for pickup drone but this is possible thanks to a little trick: all ocb values littler than 512, that you set to real drone, will be inherited by the pickup drone created dynamically by plugin code.
About the meaning of these values, they are the same you could set in pickup items and therefore:
(taken by [OCB LIST) of Reference panel of NG_Center):

0 = the object is on the floor (pickup in an old stylee)
1 = the object is `hidden' (Lara plays a stick hand in wall type animation)
2 = the object is attached to a wall (Lara has to use the crowbar)
3 = the object is on a high pedestal
4 = the object is on a low pedestal
64 += Add 64 to any of the above if you want the item activates a pickup trigger.

For instance: if you want placing the (future) pickup drone on a low pedestral (ocb =4) and don't supply a battery (ocb = 512) you'll have to set 516 as ocb of real drone.

Preparing Script commands

In this chapter I'll not repeat the list of fields and flags (constant values) for Drone's script commands, since you can already find it in Reference panel of NG_Center, looking for "CUST_DRONE" , "DRF_..." or "VIEW_..." constants. Rather here, I'll try to explain in depth the outcome of some specific settings helped in this description by some pictures

Required script commands

First and main script command is "Customize=CUST_DRONE" script command, of course.

Customize=CUST_DRONE command
You have to type it in the script level section of first level where you place the drone. While, about next levels, you could also omitting it, since it will be preserved all data got from first level.
Anyway, if you want change some settings, in next levels, you can add a new Customize=CUST_DRONE command, remembering to reset drone hub with correct ocb value in drone object placed in that level: see Drone OCB: 1024

Other script commands to add are those linked with some drone features you enabled.

Image= script command
For instance, if you set a mask image to show in FPV (First Person View) cam, typing a valid ID in MaskImageIndex field, you should set also the Image= script command with that id.
The mask image, indeed, will be displayed only when it's working the VIEW_CAM_DRONE and not for VIEW_CAM_LARA or VIEW_CAM_CHASE_DRONE cam.
If you want displaying a sort of "frame" , where only in the middle it will be visible the scene (like it happens with binocular mask) you should use transparent color (Red=255 ; Green=0 ; Blue=255) to create this "window" and select in Image= command to show full screen image.
Anyway you can also displaying a littler image, for instance like a info bar at bottom of screen and then set specific drone strings to be showed over this info bar.
If you want that the frame (the opaque side) or the little info bar, hosted in correct way the drone texts (distance, height, signal strenght or warnings) you should use positional formatters in default drone strings (starting from FirstDroneExtraString), to set correct position for each string, to get that the text fits correctly in the mask you created.
For this job I remind you that you can use the "Get Screen Frame" tool, in first "Tools" panel of NG Center program, to compute the microunits to use for the formatters of drone strings.

Notes:
- If you don't want a Mask Image you can type IGNORE in this field.
- Not all setting of Image= script command will be used, only that about size and position of the image, further special effects or durate setting, will be ignored.
- You should always remember to add these image command in next level sections, also when you omitted to type a new Customize=CUST_DRONE command, and taking care to use same IDs you used in first level, where you typed first (and only, probably) Customize=CUST_DRONE command.

Parameters=PARAM_SHOW_SPRITE command
Another script command that could be required by some drone settings, is Parameters=PARAM_SHOW_SPRITE command.
If you used the DRF_NOISE_EFFECT_ON_NO_SIGNAL flag, you'll have to type a Parameters=PARAM_SHOW_SPRITE command with info about sprites to use for noise effect on drone's monitor.
For instance, in Drone demo we have this command:

Parameters=PARAM_SHOW_SPRITE, 1, FSS_ANIMATE, 67, 78, 872, 775, CUSTOM_SPRITES, 0, IGNORE, IGNORE, IGNORE, $403

In above command there are indications about the screen zone (in micro units: "67, 78, 872, 775") where to apply sprites, taken from "CUSTOM_SPRITES" slot, by first ("0") sprite with an animated sequence of 3 sprites and with a frame delay of 4 frames ("$403").
Notes:
- Also this command has be reported in all next levels where there will be the drone, with same Id used by Customize=CUST_DRONE command of first level.
- Plugin demo uses two sprites: first sprite (really a sprite sequence) to simulate noises on screen and the second to show the "LOST DRONE" text over noises. For this reason you'll have to type two Parameters=PARAM_SHOW_SPRITE commands and the first id has to be for noise sprites and you'll type this id in SpriteScriptId field. While. about the second sprite, that for "LOST DRONE", it will have the id + 1 respect at first.

Customize=CUST_TEXT_ON_FIXED_CAMERA command
You should type this command in each level section where you mean using the drone:

Customize=CUST_TEXT_ON_FIXED_CAMERA command

It's necessary because, otherwise, the text of telemetry will be not visibile when there is the mask image for VIEW_CAM_DRONE (where it will be displayed the controller's monitor

Other commands
Above commands are specific for drone manageent, then there could be other script commands linked with Customize=CUST_DRONE command, of course.
For instance, if you enabled DRF_ENGAGE_TGROUP_ON_ITEM_COLLISION or DRF_ENGAGE_TGROUP_ON_STATIC_COLLISION flags, you'll have to type in Extra2 field the TriggerGroup ID to perform when there is that collision and so, in this case, you'll have to type (and copy to next level sections) also that triggergroup, of course.

Different Cam Views



You can enable (or less) three different views when drone is flying (or ready to fly):

Adding or less the relative VIEW_CAM flag, you'll enable or less that kind of view. I suggest to let all them enabled (and in this case you can use the VIEW_CAM_ALL flag) because each of them has some quality.
The VIEW_CAM_LARA, in spite doesn't work so fine when drone is far, is very realistic in taking off phase: it could look weird that lara doens't look at drone while it is going to take off.
The VIEW_CAM_CHASE_DRONE view is only one to show fine the drone object, and it should be a pity don't see ever the drone by a close view.
While the VIEW_CAM_DRONE view will show full telemetry and follow the real standard about FPV flying, with the view of drone and all data about distance, signal strenght ect.

When display telemetry and warning messages

There are some VIEW_ flags that allow to disable telemetric data or warning messages on some cam views.
Theoratically, you could have telemetric data also in VIEW_CAM_CHASE_DRONE view but, if you think it's not realistic or they are ugly to see, you can disable them adding the VIEW_NO_TELE_ON_CHASE_CAM flag (to remove telemetric data) or the VIEW_NO_WARNINGS_ON_CHASE_CAM flag to remove warnings in chase cam.
About the VIEW_CAM_DRONE view, it's not possible disabling messages or telemetry but you can disable a single telemetric data (or warning messages) simply removing the relative string from script language file.
About VIEW_CAM_LARA view, it's not expected there was telemetry and so there is no flag to remove it (by defaulti it will be not displaied) anyway you can use the VIEW_NO_WARNINGS_ON_LARA_CAM flat to hide also warning messages when VIEW_CAM_LARA is working.

Drone strings management

Drone will display many texts when it's working: telemetric values (about distance, altitude, compass, signal strenght ect) and many warning messages to describe its status (landing, take off, collision, low signal ect)
All these have to be ExtraNG strings and they have to follow a specific sorting:

Index Meaning
--------------------------------------------------------------------------------
220: #376:970:F8 for Help (tip displayed when lara grabs the controller)
221: #14:924:Distance %3.1f m (Distance for "chase cam" view)
222: #R200:954:%3.1f (Distance for "drone cam" view)
223: #14:970:Height %3.1f m (Altitude for "chase cam" view)
224: #R373:954:%3.1f (Altitude for "drone cam" view
225: #295:970:Battery %d %% (Battery Level for "chase cam" view)
226: #R723:954: %d (Battery Level for "drone cam" view
227: #295:924:Signal %02.1f %% (Signal strenght for "chase cam" view)
228: #R550:954:%2.1f (Signal strenght for "drone cam" view
229: #586:924:Compass %s %+d (Compass data for "chase cam" view)
230: #R935:954:%s%+d (Compass data for "drone cam" view)
231: #50:250:Commands\n---------\nMove the drone: cursor arrow keys\nMove upward: Rush\nMove downward: Duck\nRotate at Left: Walk+Left\nRotate at Right: Walk+Right\nTilt up the Camera: Walk+Up\nTilt down the camera: Walk+Down\nChange cam view: DrawWeapons (Space)\nTake off : Action or Enter\nLanding : Action or Enter\nShow this help : F8 key\nScreenshot : F3 Key\nQuit Driving : Inventory\n\n(Escape to remove this help)
232: #C499:130:Warning: Low Signal
233: #C499:130:Warning: Low Battery
234: #C499:130:Warning Lost Drone
235: #C499:130:Emergency Landing
236: #C499:130:Return To Home
237: #C499:130:Looking for landing
238: #C499:130:Magnet: taken item (displayed when drone lands over the given key item)
239: #C499:130:Proximity alarm: obstacle (Displayed when drone stops to avoid to sbam against an obstacle)
240: #C499:130:Landing
241: #C499:130:Ready (default message: no news and drone is waiting for commands from controller)
242: #C499:130:Recovering last safe position
243: #C499:130:Take Off
244: #C499:130:Failed: %s (Displayed when drone failed to perform some action, like "return to home", "recovery last safe position" ect)
245: #C499:130:Mayday! Falling down! (Battery is out of power while drone was flying)
246: #C499:950:Battery is out of power (This warning will be displayed when player tries to begin to drive drone but battery is out of power)
247: #C499:950:Impact (Displayed after rebounding against an obstacle and there was no proximity allarm enabled)

Above is the list you find in "english.txt" file of drone demo. (I added some note in round parenthesis)
You can modify above strings, of course but let their order about index.
If you want change indices of above strings (maybe because you already used those indices in your level) you can do that, just only that the relative position was the same (the sorting) and then you'll have to type in FirstDroneExtraString field of Cutomize=CUST_DRONE command, the index of first string of above list. In above example the value should be "220"
Note: it has been added to NG_Center a button own to change in fast way indices of many strings on one shot.

Positional and numeric formatters

If you want changing one of above strings that has a "%d" formatter, remember that, where there is that formatter, it will be displayed the given numeric value in game, therefor try to keep that formatter in your new text.

If you want displaying above strings to fit placefolder you drew in your Mask Image (see MaskImageIndex field), you should use positional formatter at start of each string, using microunit values for its position on screen.
For instance, if you want having the "Warning: Lost drone" (and probably all other warning messages) at bottom of the screen, you should change those strings like this:
"#C500:890:Warning: Lost Drone"

The coordinates are millesimals, so X origin will be aligned ("C" = Center) at center of the screen, while the Y origin at 89% of screen height
Probably you'll have to perform some attempts to align correctly all texts to your mask image. BTW, remember that there is the "Get Screen Frame" tool, in [Tool] panel of NG Center program, to help you in this job.
You can set three type of alingment:
"L" : Left alignment
"C": Center alignment
"R": Right alignment
The coordinate you supplied will be set in according with the alignment.
For instance the warning messages in drone demo have all this positional formatter:

#C499:950

It means : set origin at half of screen (horizontally) 499 on 1000
and place the middle of the string in that position. The middle, because aligment was center ("C")
If we set a left alignment, first (at left) character will displayed in given coordinates, while with "R" alignment, it will be last (righter) chracter to be placed at that coordinates.
If you omit any alingment letter, the default alignment will be Left.

Two different telemetric data

There is a different formatting of some strings in according with current cam view.

-When the view mode is VIEW_CAM_LARA mode, there will be NO displaied text. It follows the logic that these messages will be showed on controller but Lara, in this view, isn't looking at controller, so she didn't see them (really there is the exception for warning messages but now we are talking about telemtetric values)

- When the view mode is not the VIEW_CAM_LARA mode, the texts will be displayed, but, about texts that host a numeric formatters (Height, Distance, Signal Strenght, Battery Level), it will be showed the extended string or the concise string, in according with the cam view currently in use.
About these pair of texts (for same value), it will be showed the first (the extended one) when drone is working in VIEW_CAM_CHASE_DRONE mode, while it will be displyed the second (the shorter one) when the drone is working in VIEW_CAM_DRONE mode and there is a MaskImage)
If a mask image doesn't exist, then the texts will be displayed exactly like it happens with VIEW_CAM_CHASE_DRONE mode, i.e. the first one for each couple.
The reason of this working mode is that, when you use a mask image, you could insert the description of thee value (for instance also with icons) in the image in graphic way, and for this reason the descriptive text should be not useful.
For instance, the original text: "Battery %d %%"
Will be displayed in VIEW_CAM_CHASE_DRONE mode in this way:
"Battery 87 %"
While it will be displayed simply as:

"87 %"

When we are in VIEW_CAM_DRONE mode and there is Mask Image.
Notes:
- The above string list is only an example, of course. If you want you can type in the second one of the pair, that should be the shorter version, also a long descriptive text. At same way, you could also remove one o more of above strings to avoid to display them and there will be error message for this omitting.

- You should use different positional formatter for an extended and the concise version, because (probably) they will have to be drawn in different position of screen.

About the "%d" placefolders for numeric values, it's useful to know that there is an advanced syntax to show numeric values.
You can replace the "%d" with one of these formatters:

%3d (It means, show alayws at least three (3) digits for this number (with no point digits) using spaces with little numbers.
Example:
" 5"
" 12"
"234"

%02d (It means, show always at least two (2) digits for this number, using "0" digit at left for littler numebers.
Example:
"06"
"00"
"43"

%3.2f (It means, show the value with point and 2 digits after the point.
Example:
" 4.54"
" 23.01"
"432.00"

%02.2f (It means, displaye the value with 2 integer digits (replace with 0 if missing) and 2 digits after the point.
Example:
"00.04"
"05.30"
"55.00"

About the special formatter "%", it will be used to format numbers (see above 4 note) but if you want to display simply a "%" character on screen, you'll have to double it.
Example:
"What is the %% percentage?"
It will display:
"What is the % percentage?"

Proximity sensor or rebounding?

A very important flag is DRF_PROXIMITY_SENSOR flag.
If you add this flag the drone will refuse to sbam aganist obstacles. It happen because, thank to proximity sensors it will be able to get in advance if the direction where player want moving it, will be free or less. If it's not free, the drone will ignore that command.
In the case you omitted the DRF_PROXIMITY_SENSOR flag, there will be another behaviour...
Drone will follow every directional command and, when it smahes against an obstacle it will rebound on that, chaning direction and losing a bit of its altitude.
By the way, the drone is unsmashable: in can falling down from any height or sbaming aganist every obstacle but it will never broke.

Computation of signal strenght

Talking about script settings that will affect a lot drone simulation, there is the DRF_WALL_REDUCTION flag.
I suggest to use it, because in this way the simultation of signal losing will be very more realistic.
With wall reduction the computation of current singal stenght will be not only based on current distance from controller, related to max distance typed in MaxDistance field but there will a further lost of signal for the intermeidate walls and their depth.
With no wall reduction, the formula to compute signal strenght is very basic: there will be calculated the percentage of current distance with max distance and that (its complement, really) will be the signal.
For instance,if you set 100 meters as max distance and the drone is at 50 meters from controller, the signal strenght will be 50 %
When the drone will reach 100 meters the signal will be 0 % and the drone will be lost.
In spite it's easy to compute this calculation is not realistic because many obstacles reduce the intensity of radio signals.
So, adding the DRF_WALL_REDUCTION flag, there will be a furhter reduction of signal in according with depth of walls found in straight line between the drone and the controller.
This computation is rather precise, look below picture.


In A picture you can seeing Lara. The distance is 19 meters on 50 meters of max distance, the signal is 66 %
Now, just only move a bit at right the drone (B picture) and it will lose the free line with Lara and the signal decrease to 5.8 (in spite the linear distance from Lara changes only a bit)
If we move furhterly at right the drone (C Picture), the signal felt to 0 and the contact with drone is lost.

Anyway, looking above pictures, don't think bad.
It's not enough only one sector to lose all signal. In above situation, moving at right drone, the straight line with controller, saw a huge raising of wall depth, at end almost the whole distance but when there is only one sector of depth, drone is yet able to receive some signal.
It's not easy working only on wall depth, anyway let's say that drone will be lost when wall depth will be by 4 sector or more, while it could also keep some signal with two or three sector, in according with current distance, of course.
The final simulation is enough realistic: Lara could move the drone behind some corner but without exagerating.
This is another reason to suggest the usage of DRF_WALL_REDUCTION flag: omitting this reduction (and, let's say) letting a big max distance, the player could vist almost the whole level without moving himself by his start point and this should be not so good. It's better he explores, moving Lara, conquering, a bit at once, new places and discoveries.
Using 50 meters as max distance and wall reduction, the player will be able to explore with drone the place where he arrived but not too farer.

Self Recovery of Safe position



Another important flag is DRF_SAFE_RECOVERY flag.
If you add this flag, until signal is low but enough to transmit, nothing happen (A Picture) but, when drone will lose signal (B Picture), it will come back to last position (C picture) where there was a good signal. In this way player will be able to take newly the control of drone.
Omitting this flag, by other hand, could get a true pain driving the drone between walls and tunnels, because, after some corner the player will lose the contact and the drone will stop to send images and it will have an emergency landing, so, at end of the story, the player will have to look for drone without a clear idea about its position.

Values of signal limits

As reference, here there are signal limits that affect some message or actions:

Note: about limit for safe recovery, it will work only if it has been enabled with DRF_SAFE_RECOVERY flag, of course.
If safe recovery was not active, the drone will land when signal is less than 5%

Taking little items: the magnet

Adding the DRF_MAGNET_SKILL flag, the drone will be able to catch little items and then taking them to Lara.
This is a interesting chance to solve some puzzles: the player see where is a key but he cannot reaching it, with Lara but ... with drone he will be.
To do work this features you have to:
  1. Add DRF_MAGNET_SKILL flag to Flags field of Customize=CUST_DRONE command
  2. Place a key item (so, an item with slot in the range: KEY_ITEM1 / KEY_ITEM12
  3. Add to ocb of this key item the value 512



Then, in game, it will be enough to do land the drone over the key (see above pictures) and drone will catch the key.
Later, when drone will land (close to Lara) and Lara will pickup it, other drone she will get also the key.

Note: in the case you thought that, in this way, it should be too easy for player get the key, you have some way to get more hard this operation:


Engage TriggerGroups on Item Collisions

You can assign to drone a very active role engaging triggergroups when drone touch some give item, moveable or static.
Using the DRF_ENGAGE_TGROUP_ON_ITEM_COLLISION or the DRF_ENGAGE_TGROUP_ON_STATIC_COLLISION flag, you can perform a given triggergroup when drone touch the wished item.
Both flags require to set in Extra1 field the item slot while in Extra2 field the id of triggergroup to perform when colliding happens.
In the triggergroup you can insert trigger to affect a moveable or an item and you can work own on item index that collided with drone, adding the TGROUP_USE_FOUND_ITEM_INDEX flag in first work of exported trigger. In spite this is not a big news, about moveable, now it's possible doing the same also for static items.

Example: to do explode static items

For instance, if you want when drone touch a given static item, the item exploded, you can type script commands like following:


;trigger group when drone collides with architecture3 (only a test)
TriggerGroup=          2, $2000+TGROUP_USE_FOUND_ITEM_INDEX, 180, $2E3

Customize=          CUST_DRONE, (other DRF_ flags) + DRF_ENGAGE_TGROUP_ON_STATIC_COLLISION, >
                                        (VIEW_ flags), PICKUP_ITEM3, PICKUP_ITEM2, PICKUP_ITEM1, PUZZLE_ITEM1, 220, 1, 2, 3, 50, 1, 33, 2

In last fields, the Extra1 field = 33 (static slot for architecture3) and Extra2 = 2 (id of triggergroup to do explode a static item)
When drone will touch that item it will explode.
Same thing you can do with moveable, of course, but in this case you have also more chances: for isntance, creating a triggergroup to open a door and the perform it when drone will touch a level switch item (for instace) and you'll get like it has been drone to engage the switch to open the door.


Please note that, above example it's not necessary if you want that simply drone smashes shatter objects, in that case just only add the DRF_DESTROY_SHATTERS flag. In above picture the effect of DRF_DESTROY_SHATTERS flag.

Giving Drone the skill to engage directly triggers

An interesting chance is to give drone the skill to engage triggers. We are talking about "heavy" triggers, of course.
You can enable (or less) the kind of heavy triggers:
Adding the DRF_ENGAGE_OVER_HEAVY flag, the drone will engage all heavy triggers simply flying over them.
While adding the DRF_ENGAGE_PAD_HEAVY flag, the drone will have to land (touching the ground) to engage an heavy trigger.
The advantage of this chance is clear: player, driving drone in some specific side, cuould engage triggers, increasing the chances to have a better interaction between drone and your puzzles.
Anyway, there could be some problem letting Drone an indiscrimante chance to engage all heavy trigger...

How to avoid indiscriminate heavy trigger activations

The problem, enabling activation heavy triggers by drone, is that many heavy triggers could have been placed for other enemies and it could happen that drone engaged randomly them , with player that to do fly drone everywhere.
There are some tricks to solve this problem.
Enable only DRF_ENGAGE_PAD_HEAVY flag, getting drone will activate heavy trigger only landing on that sector, and get impossible for drone to land over sectors with heavy trigger for enemies. To forbid landing just change a bit the sector to avoid it was flat. Just only a little tilt and drone will be not able to land on that sector.
About avoiding random activation of heavy trigger flying (and in this case we are talking about DRF_ENGAGE_OVER_HEAVY flag), only chance is to create obstacles to avoid that drone was able to reach that sector. Using gray sector is easiest solution but it's necessary taking care that those boxes didnt stop also enemies that should engage the trigger.
There are also some drone triggers that could help you to forbid drone to fly over some zones. See next chapter: Triggers to forbid drone to visit some zones

Drone Triggers

Plugin_drones support some triggers focused on drone management, of course.
I remind you that, to "see" them, you have (in Set Trigger Type Window), to select in "Plugin/Engine" combo box, the "Plugin_drones" voice.

Triggers to forbid drone to visit some zones

The commonest way to forbid some zones is to place gray sectors, of course, but there are some problem usign this method with drone.
Placing too many gray sectors, we could stop also to other enemies to visit those zones, and perhpas it was not that we wished.
More, it's not so realistic to see the drone sbamming against an invisible wall (the gray sector) while it's flying.
So, to avoid above problems, we can place some triggers to "sabotate" drone when it's going too close to forbidden zones:

48:Signal. Decrease Signal strenght adding a wall of click depth<&> in (E)way
54:Signal. Decrease Signal strenght adding a simulated distance of <&>meters/yards in (E) way

The trick to reduce signal works better than an invisible wall. Practically you should place heavy triggers with one of above triggers in the path that drone should follow to reach forbidden zone and reduce drammatically the signal strenght. At that point, drone will have to come back to recover last safe position or, if it's not enabled the safe recovery, it will land immediately. In both case the drone has not been able to reach the forbidden zone.

Change drone settings in game

Some triggers are able to change drone' settings that you usally set in Customize=CUST_DRONE script file.
This chance allows to adapt drone's features in according with different zones of same level.
For instace you can enable or disable all DRF_ flags, using triggers:

50: Customize Flags. Add <&>DRF_ flag for currently loaded Customize=CUST_DRONE script command
51: Customize Flags. Remove <&>DRF_ flag for currently loaded Customize=CUST_DRONE script command


Tips about changing dynamically flags



Customize triggers

With some triggers you can change each customize=CUST_DRONE's field in game time:

56: Customize. Set <&>value to (E)field of Customize=CUST_DRONE command
59: Cutomize. Copy Trng Variable CurrentValue value to <&>field of currently loaded Customize=CUST_DRONE command



Change items for collision detection

You can creating nice effects with DRF_ENGAGE_TGROUP_ON_ITEM_COLLISION or DRF_ENGAGE_TGROUP_ON_STATIC_COLLISION features but it could be annoying having only one moveable (or a static and not in same moment) with this chance.
Thanks to flipeffect 56 or 59, you can set another kind of item for this interaction and, usually, also a differnt triggergroup to peform. To get this chance, just only that you perform in right moment a customize trigger.
For instance, let's say that at begin of the adventure, you want that Drone was able to interact with a switch that keeps closed a door where lara wants coming in.
In this first phase you'll set a DRF_ENGAGE_TGROUP_ON_ITEM_COLLISION flag (supposing it was a moveable), then you'll set in Extra1 field the slot of this item, let's say a SWITCH_TYPE1 item and, finally, you'll type in Extra2 field the id of triggergroup to perform, let's say Id =13.
Well, when Lara finally got to drive the drone, to do sbam it aganist that switch, you can perform a customize trigger to change the fields: Extra1 and Extra2 (slot type and triggergroup to peform) and furtherly also the kind of flag (for static, this time, it may be) and in this way, you can prepare the collision skill for another item that will be met by lara later in the adventure.

Trigger for variable managements

There are two trigger to get easier the usage of variable with data of drone:

70:Variables. Move index of (E)Drone item to <#>trng variable
71:Variables. Move the value from (E)Field of real drone to <#>trng variable
72:Variables. Move the value from <#>trng variable to (E)field of real drone

Thanks to above trigger you can creating advanced scripting, using above exported triggers in your triggergroup command.

Fields of Real Drone

ContactFlags
This field has to be seen as a serie of flags, each value is a power by 2, so flags like: 1,2,4,8,16,32 ect
It could be used after a collision to detect what mesh (of this object) had the collision.
The link between flag and mesh works in this way:


Flag  Mesh
-----------
1 = mesh 0
2 = mesh 1
4 = mesh 2
8 = mesh 3

ect.
Anyway I'm not sure that these flag were correctly set after all detections of collision

MeshVisibilityMask
This field has same method of flags for specific meshes seen in Contact flags, but in this case is to enable/disable the visibility of given mesh.
If the the corresponding flag is present, the mesh will be visible, otherwise it will be not.

Transparency
This field will be used for semi-trasparency attribute of current object.
The range is 0 - 255, where 255 is fully opactiy and 0 is invisible.
Anyway take care: it used to prepare the vanishing (and removing) of just killed enemy, so if you set a value different than 255 the moveable could increase the transparecy until to be removed.

Facing ClockWise
This is the least common orienting (facing).
Imagine lara in stand-up position, clockwise degrees will be applied to do rotate her like a needle, with her arms moving until to be parallel to the ground (using a picture it should have been easier to explain, ok)

Flags Main
I've not yet discovered the meaning of all flags, anyway here we have some descriptions:

#define FITEM_ACTIVE 0x0001 // item is active (it will move) flag set after calling AddActiveItem()
#define FITEM_CREATURE 0x0002 // Creatures are invisible until they have not been triggered
#define FITEM_NOT_VISIBLE 0x0004 // the item was not visible at start
#define FITEM_GRAVITY_AFFECTED 0x0008 // the item is falling down (or jumping up) and it's subject to gravity simulation, currently
#define FITEM_ITEM_HAS_BEEN_HIT 0x0010 // the item has been hit: with weapons (but not grenade)
#define FITEM_NOT_YET_ENABLED 0x0020 // the item has not yet been enabled (triggered)
#define FITEM_KILLED_WITH_EXPLOSION 0x0040 // trng flag, added to remember that this enemy has been killed with an explosion
#define FITEM_POISONED 0x0100 // enemy (or lara?) has been poisoned
#define FITEM_AI_GUARD 0x0200 // enemy was over a AI_GUARD item
#define FITEM_AI_AMBUSH 0x0400 // emeny was over a AI_AMBUSH item
#define FITEM_AI_PATROL1 0x0800 // enemy was over a AI_PATROL1 (and perhaps AI_PATROL2)
#define FITEM_AI_MODIFY 0x1000 // enemy was over a AI_MODIFY item
#define FITEM_AI_FOLLOW 0x2000 // enemy was over a AI_FOLLOW item
#define FITEM_THROWN_AMMO 0x4000 // (not sure) it used with visible ammo like greande or arrows of crossbow


Flags Swap Mesh
Also this field works like ContactFlags and MesVisibilityMask fields, where each flag (a power by 2 value) works for the given mesh.
In this case the flag will signal if linked mesh is main or flipped.
In tombraider all moveable have (teoratically) two meshes for each mesh position, and it is possible (using own this field) to show one or another.
Really only few moveables used this chance, most of them have always same mesh as main or flipped, anyway you could giving a look to skeleton or von croy to see some of their flipped meshes.



Set temporarily max altitude

Between customize triggers there are some of them having a target that is not really a change of previous setting but rather a fully new feature.

67: Customize. Set as max altitude for drone the value of <&>sectors over current floor in (E)way.
68: Customize. Remove max altitude limit.

The chance to set a limit for altitude is own one of them.
By default drone has no limit about its raising, it will be stopped only by room geometry when it finds the ceiling. Anyway, in some circustances you could need to limit the chance (for player) to move up the drone, since the tomb raider's sky is not really endless. It should bad to see the drone sbamming against invisible sky obstacle. If you want, in some side of the level where, proabably there is a "low" sky, you could avoid that player moved the drone against the sky using flipeffect 67.
The main advantage of this trigger is that, once you set an altitude limit, the attempt by player to pass it, will not affect a "Proximity sensor alert" or an "Impact" message (that could look weird, against the sky) but simply the drone will not move up furtherly, ignoring the move up command.

Triggers to change VIEW_ flags dynamically

You can enable or disable also VIEW_ flags, of course.
BTW, there is a reason to use specific trigger to DRF_ or VIEW_ flags, rather than using the generic trigger to change fields of Customize=CUST_DRONE command. If you used the flipeffect 56 to change VIEW_ or DRF_ fields (theoratically possible) you should enable or disable in same moment all flags in that field, and this could be complicated to hande, while, using specific customize triggers for flags, you can work on a specific flag to add or remove, letting unchanged all other flags.

57: Customize Flags. Add <&>VIEW_ to currently loaded customize=CUST_DRONE command
58: Customize Flags. Remove <&>VIEW_ flag to currently loaded customize=CUST_DRONE command

The targets to change dynamically VIEW_ flags are not so obvious, anyway you could wishing forcing some view (disabling all others) in some topic moment of the game, or removing warning messages for some reason.

Triggers for Drone cutscenes

For drone cutscenes I mean the chance to do fly the drone, driven whereby triggers, to play some action in story board.
These are triggers you could use to create a drone cutscene:

60: Cutscene. Set <&>Camera View for drone with (E)degrees of tilt
61: Cutscene. Force drone to fly and to reach <&>LARA_START_POS target, previously reaching (E)meters height
62: Cutscene. Change vertical position of drone by <&>game units, moving it in(E) direction
63: Cutscene. Move drone camera to reach <&>tilt degrees, in (E)seconds


To do drone following a path

In a Drone cutscene is not Lara to drive the drone but some triggers. Main trigger to do move Drone is flipeffect 61:

61: Cutscene. Force drone to fly and to reach <&>LARA_START_POS target, previously reaching (E)meters height

Usually you'll create a drone cutscene at begin of the level, because, in other situation is not easy to be sure about where the drone was, since it's Lara (the player) to move it.
Differently, at begin of level you know where it is and you could to do start a cutscene, to do follow it a path to pass close to Lara or to show drone cam looking at Lara, like in una fly-by camera sequence.
The target to reach will be where you placed an LARA_START_POS AI item, with a specific (unique) ocb value.
If drone was on the ground, it will take off, raising at given height and then it will move horizontally to go over the target point and the it will land.
It has to be you to calculate that drone had a free way in this path, and, in the case it meets an obstacle the cutscene will fail with an emergency landing.
If you want, you can place on the path of first flipeffect 61, another flipeffect 61 with a different target, in this way the drone will change direction to chase this new target. Using this method you can create complex path, like you were using the AI_FOLLOW items to do move a baddy for a long path.

Set the view type for the Cutscene

To improve the outcome of drone cutscene are very important triggers to change the current view:

60: Cutscene. Set <&>Camera View for drone with (E)degrees of tilt
63: Cutscene. Move drone camera to reach <&>tilt degrees, in (E)seconds

While the flipeffect 60 change suddenly the view type and tilt degrees of camera, the flipeffect 63 allow to change smoothly the degrees of camera. So you should use flip 60 only at start, to set what will be the first camera mode and tilt and then, while the cutscene is in progress, you could use flipeffect 63 to move slowly the cam tilt.
In spite you could use a triggergroup or an Organizer script command to plan whole cutscene, it's probably safer to place these triggers on sectors (following the path) as "heavy" trigger and enable the DRF_ENGAGE_OVER_HEAVY flag, to do that was the same drone to activate triggers for its cutscene.

Note: the cutscene triggers will work ONLY while there is a cutscene in progress (or to start one) but they will have no effect when drone, driven by Lara, will fly over those sectors.

Start Follow-me feature

Many GPS drones have the follow-me feature. In spite it's not so useful in our situation (Tomb raider game), I added anyway this feature but it works only as cutscene, it's not a standard command to control the drone.
The trigger:

73:Cutscene. Follow me. Follow Lara, keeping <#>min distance and (E)Min height respect Lara

will engage the follow-me.
It works only if, when this trigger is engaged, the drone in on the ground with close arms.
This means that it will not work with drone in inventory, of course, but neither if drone is currently flying or under the control of Lara.
In drone demo, you can try the "follow me", letting the drone on the ground and then moving Lara over the "Todos" sector:



Once engaged the trigger, the drone will take off and it begins to follow Lara.


Note: also when it has been set a drone cam (chase or proper drone cam), the player is able to see from Lara with the standard [LOOK] command (C Picture).

Settings for Follow-me trigger

In "follow me" trigger, you have to set the "min distance" and "min height". It's advisable that you set the correct values to be sure that drone doesn' collide with Lara (at least you didn't wish own this behaviour).
MIn height it means that dorne will move down to get closer to lara but, keeping the min distance respect lara. About height I remind you that Lara position is on her feet, so you should set a "min height" that should be at least 1024 units, since tall of Lara is about 760 game units.
The "max distace" is alike of "min height" but in this case it work only as horizontal distance.

Note: Follow-me feature is not perfect, if Lara turns quicly a corner, it's possible that drone was not able to follow her, because the compute of direction, works only on straight lines or moving up/down but if lara is hidden by a wall (stopping the straight line) the follow me will be not able to chase Lara.
For these limitation, you should engage "follow-me" only in wide rooms and where Lara cannot hid herself easily.

Trigger to do perform a full rolling


69:Cutscene. Force drone to perform a full rolling in <&>direction, in (E)Seconds

The "rolling" (other times called "flip") is when drone turns on its axis, performing a 360 angle. This skill is not useful of course, anyway it could be amazing to watch, while drone is performing a cutscene.
In Demo level, at first drone cutscene, the drone will perform also a flip:


Please, note that this flipping (or "rolling") is really only a simulation, in the reality, the drone object doesn't flip really, only the cam will do. For this reason this effect works only when there is a cam view (drone cam or chase drone) but it will have no effect when the source cam is not from drone.
About this simulation, there is an exception at rule that drone doesn't really turn, when current cam mode is chase drone view. In this case, it will be performed really a 360 turning of drone.

Trigger to stop drone cutscene

You can stop any cutscene usign follow trigger:

74:Cutscene: Stop current cutscene in <#>way

One of "way" is whereby Return To Home command.

Triggers to change Drone management

There are triggers that look having a target vey alike than Customize triggers and it's true, but these triggers work in a differrent way: not changing fields of Customize script command but rather some internal data in drone management, that should be not available via customize command.
These are triggers to modify current drone data in run-time:

47:Battery. Set <&>Battery level for battery currently plugged in Drone
52:Text. Display <&>Drone Message in (E)way
53:Text. Remove <&>Drone Message
64: Command. Send <&>command to Drone
65: Command. Divert drone, forcing it to reach <&>LARA_START_POS position in (E)way
66: Pickup: Set as drone had picked up the <&>inventory item in (E)way


Change current battery level

This trigger:

47:Battery. Set <&>Battery level for battery currently plugged in Drone

It's a good example of difference between customize triggers and trigger to change drone's managemnet, indeed, the current level of charge of battery is not a field of cutomize script command but only a value in run-time.
You could change the level battery for different reasons:
- Help drone to reach a very long target, giving it a recharging
- The opposite, cut off the chance of drone to reach some target, letting it only few energy and forcing player to do land the drone.

Display custom warning messages for drone

Triggers to force drone to display some message:

52:Text. Display <&>Drone Message in (E)way
53:Text. Remove <&>Drone Message

could be used to underline some particular situation in game.
First of all, I remind you that flipeffect 52 will display the message in same position of drone's messages and (if you wish) following the message list of drone, i.e. your message could be mixed (earlier or later) with other "official" drone's message. This is main difference between usage of this trigger, rather a common flipeffect to display a text on screen.
About examples we could suppose situations like following:


Note: you can display a text different by default drone's messages, adding this your new text at end of drone's messages list in NG Extra string sections, but you can also using some default drone text if you wish. Anyway remember that the index you'll set as parameter it will be NOT an absolute index but the offset index from Index First string. For instance, since in drone demo the first drone string is that with index = 220 and last drone string is that with index = 247, if you want adding a new custom text, you should type that as index 248 and then, in parameter of flip 52, set 28 to select the new string, since 220+28= 248

Triggers to interfere in drone driving

These triggers could remind the cutscene triggers but with a fundamental difference: cutscene triggers work only when Lara's not driving the drone, while these other triggers work own when Lara IS leading the drone.
Note: when a command set with following triggers is in progress, the player will be not able to control the drone.

64: Command. Send <&>command to Drone
65: Command. Divert drone, forcing it to reach <&>LARA_START_POS position in (E)way

If you that some trap or enemy can attacking the drone you could use some of these triggers to affect the drone.

Simulating an attack against drone

For instance, the flipeffect 64 has following commands:

1: Force landing
3: Shake drone and to do lose some altitude
2: To do fall down the drone (plummeting)

As you can see, they could be used own to evidence the conseguence of an attack on drone.
With "Force landing" or "To do fall down the drone" you can getting it lands (after this attack) and the "Shake drone" it's perfect to show some attack received in that moment by drone.

Diverting drone out of cutscenes

The trigger to divert drone:

65: Command. Divert drone, forcing it to reach <&>LARA_START_POS position in (E)way

It looks very alike than cuscene drone but in this it will work when drone is flying, controlled by Lara.
In spite of this difference its working mode is the same, so read also To do drone following a path chapter for more infos.
About specific features of flipeffect 65, we can see the "way" to operate:

0: Use 2d horizontal (x,z) position
1: Use 3d position (also y position)

Sinc this is a bit different than that for cutscenes.
If you use "3d position" (about the LARA_START_POS target) it means that the drone will have to reach the target, also landing in the case the target was on the floor.
While, with "Use 2d horizontal (x,z) position", the drone will move over same sector of that target but preserving current height and, therefor, ignoring the Y position of LARA_START_POS. In spite this second way could look weird it's very comfortable in many circustances, in particular when we want to do drone a long path, with different LARA_START_POS items. In this situation we'll have no need to move up the AI item trying to verify a correct height, but simply we'll place (on ground) the path in orizontal ward and only at end, we'll force a landing.

Global Triggers for Drone

Drone plugin supports two drone specific global triggers:

GT_DRONE_COLLIDE_STATIC (180)
GT_DRONE_COLLIDE_ITEM (181)

Both work to be engaged when drone is colliding an item (static, or moveable).
You can use them in same way of trng global triggers.
For instance, if you want executing a given triggergroup when drone touches the LEVER_SWITCH item slot, just typing this command:

GlobalTrigger= 1, IGNORE, GT_DRONE_COLLIDE_ITEM, LEVER_SWITCH, IGNORE, 5, IGNORE

In above example, when drone collides with an item of LEVER_SWITCH type, it will be performed the triggergroup with id = 5

In the case you want monitor a collision with a static item, just using the GT_DRONE_COLLIDE_STATIC global trigger type.
For instance, to perform a triggergroup when drone touches the FURNITURE3 static slot (static id = 13), you can type a command like this:

GlobalTrigger= 2, IGNORE, GT_DRONE_COLLIDE_STATIC, 13, IGNORE, 8, IGNORE

In above example, it will be performed the TriggerGroup with id 8, when drone collides with a FURNITURE3 (id = 13) static item.

To do use GT globalTriggers or drone DRF_ flags to detect collisions?

As you can see, you can get same final effect (the execution of a triggergroup) for some collision with item or static, in two different ways: using a global trigger (like GT_DRONE_COLLIDE_ITEM or GT_DRONE_COLLIDE_STATIC), or enabling a drone flag (like DRF_ENGAGE_TGROUP_ON_ITEM_COLLISION or DRF_ENGAGE_TGROUP_ON_STATIC_COLLISION).
The reason of this double chance is that, when I realized that there were some limitations about drone flags for collision, I set to add the two global triggers.
The limitation about flags is that when you use a flag (for instance to detect collision with moveable item) you'll have to use ExtraParam1 and ExtraParam2 to set slot and triggergroup to execute, but this means that, or you can using a flag for item collision, or for static collision but not both in same moment.
Differently, using GT_ global triggers, you can set different execution for collision with many different moveable or static items in same moment.
So, global trigger management, gives you more chances but, by other hand, the usage inside the Customize=CUST_DRONE command is easier, since you can omit to type another script command like the "GlobalTrigger" command.

Profiling section

Profiling is a news of Plugin_drones.
To take advantage of this new chance it could be advanced level builders, other that programmers, of course.
For "Advanced level builders" I mean level builders that are able to load the sources of some plugin in Visual Express C++ (or other compatible C++ compiler), performing some little change to the source and then building newly the plugin .dll library (command F7, or menu command: [Debug/Build Solution])

How to modify hardcoded settings of drone

The advantage of profiling section is that the risk to damage the code with wrong mods, is very little.
You find profiling section in "Constants_mine.h" source of pugin_drones.
This is the begin of profiling section:

// ---------- PROFILING CONSTANTS FOR DRONE -----------------

// changing below values you can affect the behaviour of the drone
// drivining/ movements drone

#define PROF_UP_KEEP_HEIGHT 10 // automatic vertical speed up, used to restore prevuous height when drone was going to loose height
#define PROF_YGAP_TO_KEEP_HEIGHT 128 // difference in height to force drone to move up to recover old height (tollerance)
                                                                                          // this will be the height of oscillation
#define PROF_GRAVITY_SPEED 5 // the drone should move down with this vertical speed (simulation of gravity)

#define PROF_VSPEED 15 // vertical speed for UP/DOWN commands
#define PROF_HSPEED 40 // Horizontal speed for movement forward/backward/left/right
#define PROF_MAX_FALLING_SPEED 64 // when the drone crash (falling down) this will be max falling speed
#define PROF_ROTATE_SPEED 512 // speed (degrees where 0x8000 = 180 degrees, to rotate drone
#define PROF_LARA_ROTATE_SPEED 256 // rotation speed for lara when she has to turn to look at drone in VIEW_CAM_LARA mode
#define PROF_FLOATING_VSPEED 2 // speed of up/down movement when drone is foating on water surface
#define PROF_GAP_SWINGING_ON_FLOATING 20 // step, up/down to move the drone on water surface. this vlaue will be multiplied by water intensity of given room
#define PROF_FLOATING_PAUSE_ON_PEAK 3 // little brak in up/down movement, when the drone is at peak of its movement
#define PROF_DISTANCE_WATER_FOR_WAVES 512 // when distanc from water surface is less than this value, there will be waves on the surface
#define PROF_DISTANCE_FROM_GROUND_FOR_WAVES 512 // to avoid waves on the ground close to water surface, there will be this safe distance before waving
#define PROF_DURANTE_PAUSE_BETWEEN_WAVES 10 // amount of frames between a "splash" effect and the next
#define PROF_TAKE_OFF_HEIGHT 512 // height (from start point) to reach, in automatic take off with ENTER command
#define PROF_MIN_DISTANCE_LARA_FOR_TAKE_OFF 512 // if lara is closer than this distance the drone will not take off (with DRF_PROXIMITY_SENSOR flag)
#define PROF_HALF_SIZE_DRONE 100 // this should be (about) the half of horizontal size of the drone. It will used to check if
                                                                                // in front (of curreen direction) or sidely, of drone there is a wall
#define PROF_FULL_HSIZE_DRONE 60 // this is (about) the size of vertical height of drone object (its collision box)
                                                                                // it will be used to check (in upward movement) if it is going to touch the ceiling
#define PROF_GAP_OVER_FLOOR 12 // keep the drone (in landing) a bit heigher than floor to have same gap of pickup drone
#define PROF_FLOAT_DISTANCE_MIN 150 // min valid distance from lara and floating drone to pickup it
#define PROF_FLOAT_DISTANCE_MAX 300 // max valid " " " " " " " " "
#define PROF_FLOAT_MAX_ORIENT_FACING 0x1800 // max difference between lara's facing and ideal facing to look at floating drone
#define PROF_FLOAT_PICKUP_MAX_SWING 0x800 // max value of inclination of pickup drone to simulate the waving on water surface
#define PROF_FLOAT_SWING_SPEED 128 // increement used to change inclination of piclup drone on water surface
#define PROF_DRONE_MAX_TILT 0x0c00 // max inclination of drone to follow directions
#define PROF_DRONE_TILT_SPEED 160 // speed to tilt drone

Practically each line starting with "#define PROF_..." is part of profiling section and you can change the value assigned to that PROF_... constant, to affect a change in drone code.
To get what is the meaning of each constant, other that its meaningful name, there is also a comment (after '\\' comment operator)

Now, here, I'll not explain each prof constant you can change (really: all ones) but I'll evidence the most interesting of them.

How to get a faster drone

If you want increse the speed of drone just increasing the speed values used by code:

#define PROF_VSPEED 15 // vertical speed for UP/DOWN commands
#define PROF_HSPEED 40 // Horizontal speed for movement forward/backward/left/right

Above are default prof constants for speed, if you change them in this way:

#define PROF_VSPEED 30 // vertical speed for UP/DOWN commands
#define PROF_HSPEED 60 // Horizontal speed for movement forward/backward/left/right

Drone will move faster in both direction: horizontal and vertical.

How to change game commands to move drone

These are prof constants for game commands:

#define PROF_GAME_FORWARD          CMD_UP // move forward
#define PROF_GAME_BACKWARD          CMD_DOWN // move backward
#define PROF_GAME_LEFT CMD_LEFT // move left
#define PROF_GAME_RIGHT CMD_RIGHT // move right

#define PROF_GAME_UP CMD_DASH // raise up the drone
#define PROF_GAME_DOWN CMD_DUCK // move down the drone
#define PROF_GAME_TURN_LEFT (CMD_WALK+CMD_LEFT) // (DOUBLE COMMAND) rotate drone in counter clockwise direction
#define PROF_GAME_TURN_RIGHT (CMD_WALK+CMD_RIGHT) // (DOUBLE COMMAND) rotate drone in clockwise direction
#define PROF_GAME_CAM_DOWN_TILT (CMD_WALK+CMD_UP) // (DOUBLE COMMAND) rotate down the drone's cam
#define PROF_GAME_CAM_UP_TILT (CMD_WALK+CMD_DOWN) // (DOUBLE COMMAND) rotate up the drone's cam

#define PROF_GAME_TAKE_OFF_LANDING CMD_ENTER // perform a take-off (when drone was on ground) or a landing (when drone was flying)
#define PROF_GAME_SWAP_CAM CMD_DRAW_WEAPON // swap type of cam view while drone is flying
#define PROF_GAME_QUIT CMD_INVENTORY // quit drone driving
#define PROF_GAME_SWITCH_LIGHTS CMD_JUMP // enable/disable landing lights
#define PROF_VK_SHOW_HELP VK_F8                    // you can modify this only using another VK_ (Windows Virtual Key) value ( but not a CMD_ value)
#define PROF_VK_CAPTURE_SCREENSHOT VK_F3 // hardcoded, you cannot change this
#define PROF_VK_RETURN_TO_HOME VK_HOME // key command to engage return to home

As you can see, in this case at right of specific PROF constant there isn't a number but another constant, like CMD_UP, CMD_RIGHT ect.
It doesn't matter, you can using these CMD_ constant like they were numbers. That is only a way to remember internal code for game command in tomb raider engine.
When you see that there are two CMD_ values, linked with a plus, like:

#define PROF_GAME_TURN_LEFT (CMD_WALK+CMD_LEFT) // (DOUBLE COMMAND) rotate drone in counter clockwise direction

It means that player will have to give both command in same moment to get that game command. In above example to do turn drone at left, it's necessary hit WALK and LEFT in same moment.
About these double commands, I remind you that, if you want set a double command for a game command that earlier was singel, you could have some problem if one of two commands were used also for other commands. For this reason (at least you were a programmer and you can modify the code in #key section), I suggest to don't convert a single command to a double command. Anyway you can convert a double command to another double command, or, convert a double command to a single command.




The Drone Demo level

Demo level show most features of drone object. In this chapter I'll show the reference for each kind of feature.

Drone Cutscene



Cutscene begins when Lara picked up last item on light blue sector (A picture) and the drone will take off (B Picture) .
On its path, the drone will engage other triggers (all of heavy type, in this case).
Let's see all serie of triggers for this cutscene...


Trigger to set view type (C1)
It's important set this trigger earlier than starting cutscene, otherwise the cam will stay on Lara and drone will be not visible.

; Set Trigger Type - FLIPEFFECT 60
; Exporting: TRIGGER(2:0) for FLIPEFFECT(60) {Plugin_Drones}
; <#> : Cutscene. Set <&>Camera View for drone with (E)degrees of tilt
; <&> : Cam chases Drone (The scene will show the drone and what it's watching
; (E) : Tilt Degrees = 0

Trigger to start the cutscene [C2]
This trigger force drone to reach the LARA_START_POS item with OCB=1

; Set Trigger Type - FLIPEFFECT 61
; Exporting: TRIGGER(257:0) for FLIPEFFECT(61) {Plugin_Drones}
; <#> : Cutscene. Force drone to fly and to reach <&>LARA_START_POS target, previously reaching (E)meters height
; <&> : LARA_START_POS with OCB = 1
; (E) : Raise to meters/yards = 1

Heavy trigger to change view mode as VIEW_DRONE_CAM (A3)
While cutscene begun with VIEW_CHASE_DRONE, from this trigger, the cam will be VIEW_CAM_DRONE

; Set Trigger Type - FLIPEFFECT 60
; Exporting: HEAVY(6145:0) for FLIPEFFECT(60) {Plugin_Drones}
; <#> : Cutscene. Set <&>Camera View for drone with (E)degrees of tilt
; <&> : Drone view (FPV Firsrt Person View, what the drone is watching with its cam)
; (E) : Tilt Degrees = 24

Heavy trigger to force a full flip (360 degrees) (B4)
It start a rolling on its axis by 360 degrees.

; Set Trigger Type - FLIPEFFECT 69
; Exporting: TRIGGER(768:0) for FLIPEFFECT(69) {Plugin_Drones}
; <#> : Cutscene. Force drone to perform a full rolling in <&>direction, in (E)Seconds
; <&> : Clockwise direction
; (E) : Seconds 3

Heavy trigger to move up the drone (B5)
This trigger is really necessary, otherwise drone is going to collide with floor in front of it.

; Set Trigger Type - FLIPEFFECT 62
; Exporting: HEAVY(32:0) for FLIPEFFECT(62) {Plugin_Drones}
; <#> : Cutscene. Change vertical position of drone by <&>game units, moving it in(E) direction
; <&> : Game units = 32
; (E) : Raising (move upstairs)

Heavy trigger to set a new target in cutscene (B6)
Own over that should the final target for cutscene, we set another cutscene trigger, giving a new target that is sector with LARA_START_POS with OCB = 2.
Using this method we could drive the drone everywhere and not only in a single straight line.

; Set Trigger Type - FLIPEFFECT 61
; Exporting: HEAVY(2:0) for FLIPEFFECT(61) {Plugin_Drones}
; <#> : Cutscene. Force drone to fly and to reach <&>LARA_START_POS target, previously reaching (E)meters height
; <&> : LARA_START_POS with OCB = 2
; (E) : Raise to meters/yards = 0

Heavy trigger to tilt down the camera (C7)
This change of tilt is dynamic and not immediate. The drone will start to tilt the camera slowly, while it's going to reach its final target.

; Set Trigger Type - FLIPEFFECT 63
; Exporting: HEAVY(572:0) for FLIPEFFECT(63) {Plugin_Drones}
; <#> : Cutscene. Move drone camera to reach <&>tilt degrees, in (E)seconds
; <&> : Degrees = 60
; (E) : Seconds = 2


Follow-me mode



Moving Lara over "Todos" sector (1 in above picture) you can engage the "follow-me" mode.
The trigger used to start "follow-me" is:
; Set Trigger Type - FLIPEFFECT 60
; Exporting: TRIGGER(7682:1) for FLIPEFFECT(60) {Plugin_Drones}
; <#> : Cutscene. Set <&>Camera View for drone with (E)degrees of tilt
; <&> : Cam chases Drone (The scene will show the drone and what it's watching
; (E) : Tilt Degrees = 30

While, to quit "follow-me" Lara has to engage the trigger on dark sector (2 in above picture).

; Set Trigger Type - FLIPEFFECT 74
; Exporting: TRIGGER(2:0) for FLIPEFFECT(74) {Plugin_Drones}
; <#> : Cutscene: Stop current cutscene in <#>way
; <&> : Returning to Home

The "follow-me" could quit also in other ways:
- The dying of battery
- A collision between Drone and some moveable item (like Lara)
See also Start Follow-me feature chapter

Killing Skeletons to get their key

To do work this puzzle I had to change a bit Skeleton object:


I changed the mesh of left hand to have it grabs the gold key (see above picture)
Then I had to add some animations to introduce the explosion with a falling down:


Above you see the animation 49 added by me. Really it is the same of an old animation but I cannot using that original skeleton's animation because that was linked (with next animation and state id) to other old animations, where skeleton got newly in stand up position.
After animation 49 (above) it was engaged the animation 50 (below):


Where the skeleton is still on the ground. In this animation there are two trng animcomands that will be engaged at frame 2 (see above picture)
The action trigger 14 to do explode the skeleton:

; Set Trigger Type - ACTION 14
; Exporting: TRIGGER(1038:0) for ACTION(0) {Tomb_NextGeneration}
; <#> :
; <&> : Enemy. Kill <#>object in (E) way
; (E) : Exploding creature

And the action trigger 97 to create the "skeleton key" item on the ground, in same position of given moveable:

; Set Trigger Type - ACTION 97
; Exporting: TRIGGER(9569:0) for ACTION(0) {Tomb_NextGeneration}
; <#> :
; <&> : Inventory. Create the (E)Inventory item at position of <#>Creature
; (E) : KEY_ITEM10           Slot=212

About on what moveable perform above actions (moveabel to kill, for action 14, and position of what moveable where place the created inventory item) I set, in anim command, to use the owner of animation of current animcommand. In this way it will be always the current skeleton to be killed the given moveable.
To do start the explosion, I set in Customize=CUST_DRONE command the DRF_ENGAGE_TGROUP_ON_ITEM_COLLISION flag and, as parameter for this feature, the Skeleton slot and, as triggergroup to execute, the triggergroup 1. See below picture:


This means that, every time drone collides with Skeleton the triggergroup 1 will be performed:

TriggerGroup=          1, $018000, 40, $211, > ;IF: Speed of drone is 40 (the max)
                               $012000, 71, $DFF, > ;Copy facing of drone to CurrentValue variable
                               $5000+TGROUP_USE_FOUND_ITEM_INDEX, 1021, $36, > ;set index of skeleton as current item memory
                               $2000, 256, $1D70, > ;copy facing of skeleton to Local Long Alfa variable
                               $2000, 435, $170, > ;Compute difference between drone facing and skeleton facing (CurValue - LocalLongAlfa)
                               $8000, 20, $462, >;IF difference between CurrentValue and 180 degrees is less than +/- 20 degrees
                               $5000+TGROUP_USE_FOUND_ITEM_INDEX, 545, $1110 ;action trigger 16: Force animation 49 for skeleton

This triggergroup is rather "advanced" as you can see. Anyway, theoratically we could have typed only the trigger to force animation 49 that engages explosion, to get simpler.
I chose to add some scripting to get harder the skeleton termination:
Now the skeleton will be destroyed only if there are following conditions:
- The drone (a moment earlier of impact) should move at max speed (40, in settings of current demo level)
- Drone and skeleton should be (about) face to face: a frontal impact.
Now let's see extended description for all triggers used in this triggergroup
Verify that speed of drone was at max value
$018000, 40, $211, > ;IF: Speed of drone is 40 (the max)

; Set Trigger Type - CONDITION 17
; Exporting: CONDITION(17:58) for PARAMETER(40) {Plugin_Drones}
; <#> : Game units = 40
; <&> : Speed. Current speed of drone is(E) than <#>game units
; (E) : Even, the same...

Take current facing of drone and copy to CurrentValue variable
$012000, 71, $DFF, > ;Copy facing of drone to CurrentValue variable

; Set Trigger Type - FLIPEFFECT 71
; Exporting: TRIGGER(3583:58) for FLIPEFFECT(71) {Plugin_Drones}
; <#> : Variables. Move the value from (E)Field of real drone to <#>trng variable
; <&> : Current Value
; (E) : Facing Horizontal (short)

Set as current item the found item index
$5000+TGROUP_USE_FOUND_ITEM_INDEX, 1021, $36, > ;set index of skeleton as current item memory
Found Item Index will be skeleton that had a collision with drone, of course.
After this trigger, all further trng variables triggers, accessing at item memory, will work on collided skeleton

; Set Trigger Type - ACTION 54
; Exporting: TRIGGER(54:58) for ACTION(1021) {Tomb_NextGeneration}
; <#> : ANIMATING14 ID 1021 in sector (2,4) of Room12
; <&> : Variables. Set the index of <#>moveable as Selected Item
; (E) :

Copy facing of Skeleton to long alfa variable
$2000, 256, $1D70, > ;copy facing of skeleton to Local Long Alfa variable

; Set Trigger Type - FLIPEFFECT 256
; Exporting: TRIGGER(7536:58) for FLIPEFFECT(256) {Tomb_NextGeneration}
; <#> : Variables. Memory. Copy to <&> Numeric Variable the (E)Selected Item Memory
; <&> : Local Long Alfa
; (E) : Facing Horizontal (Short)

Compute difference between facing of drone and facing of skeleton
$2000, 435, $170, > ;Compute difference between drone facing and skeleton facing (CurValue - LocalLongAlfa)
This operation gives us the different of facing between drone and skeleton. When these two items are, one in front to other, the difference should be by 180 degrees. Anyway, since tomb raider items the degrees works as $10000 = 360 degrees, the 180 degrees of differee, should $8000

; Set Trigger Type - FLIPEFFECT 435
; Exporting: TRIGGER(368:58) for FLIPEFFECT(435) {Tomb_NextGeneration}
; <#> : Variables. Numeric. Perform following (E)operation between CurrentValue and <&>Variable with outcome saved to CurrentV
; <&> : Local Long Alfa
; (E) : Subtract (CurrentValue = CurrentValue - Variable)

Verify if difference is about 180 degrees ($8000)

; Set Trigger Type - CONDITION 98
; Exporting: CONDITION(98:54) for PARAMETER(20) {Tomb_NextGeneration}
; <#> : 20: Tollerance +/- degrees = 20
; <&> : Variables. Facing. CurrentValue variable is close to tomb raider facing (E)degrees with +/- tollerance of <#>degrees
; (E) : $8000 (South 180 degrees)

When all conditions are true, perform animation 49 of skeleton
$5000+TGROUP_USE_FOUND_ITEM_INDEX, 545, $1110 ;action trigger 16: Force animation 49 for skeleton
Please, note that, in below trigger, doesn't matter what was (when exported) the object index, since we are using the TGROUP_USE_FOUND_ITEM_INDEX flag, and so it will the index of current skeleton to be used.

; Set Trigger Type - ACTION 16
; Exporting: TRIGGER(4368:54) for ACTION(545) {Tomb_NextGeneration}
; <#> :
; <&> : Force (E) animation (32-63) for <#>object
; (E) : 49 Animation


Catch a key with drone



Only way to catch the skeleton key (see above picture) is to do fly the drone inside that little room and to do land it over the key. The key will be caught by drone (thanks to its magnet) and then Lara could take it when she will pickup the drone.
To enable this skill, you have type in OCB value of given key item (it works only with KEY_ITEM objects) the value 512.
Then you have to add to DRF_ field of customize=CUST_DRONE command, the DRF_MAGNET_SKILL flag



Destroy shatters with drone



Setup for this skill, smashing shatters, is very easy: just simply add the DRF_DESTROY_SHATTERS flag to DRF_ field of customize=CUST_DRONE command

Open the door with push button for drone



Final puzzle works in this way: when drone hit the push button (see above picture) it will be engaged the GT_DRONE_COLLIDE_ITEM global trigger.
It will be caught by this script command:

GlobalTrigger= 1, IGNORE, GT_DRONE_COLLIDE_ITEM, ANIMATING1, IGNORE, 2, IGNORE

The push button is in ANIMATING1 slot.
So, when drone collides with Animating1 it will be performed the TriggerGroup=2.

TriggerGroup=          2, $5000+TGROUP_USE_FOUND_ITEM_INDEX, 1160, $10F, > ;Force (E) animation [1] for <#>object
                               $5000+TGROUP_USE_FOUND_ITEM_INDEX, 1160, $36, > ;Variables. Set the index of <#>moveable as Selected Item
                               $2000, 256, $11FF, > ;copy ocb of button to current value
                               $2000, 301, $3, > ;convert ngle item index to tomb raider index (currentvalue)
                               $2000, 245, $FF, > ;set as "current found item index" the value of currentvalue
                               $5000+TGROUP_USE_FOUND_ITEM_INDEX, 224, $11A ;trigger to open door

Later we'll explain better above TriggerGroup

The push button object

This is an easy item and it could remind a switch.
It has only three animations:



Advanced scripting for many doors/buttons

In spite in drones demo there is only one button, the scripting could handle many couple doors-buttons of this type.
Since the script receive only the index of push button but it has no info about the door to open, I set up in ocb of button the (ngle) index of the door to open.
Then the script will read from the button this index and it will use it as door index to open.
Here there is the script in detail...

Change the button as "green"
$5000+TGROUP_USE_FOUND_ITEM_INDEX, 1160, $10F

; Set Trigger Type - ACTION 15
; Exporting: TRIGGER(271:0) for ACTION(1160) {Tomb_NextGeneration}
; <#> : LARA ID 1160 in sector (4,8) of Room2
; <&> : Force (E) animation (0-31) for <#>object
; (E) : 1 Animation

Since we set the TGROUP_USE_FOUND_ITEM_INDEX, the original "LARA" object will be replaced with found item index, that is the index of push button where drone collided.
Performing animation 1, the push button will change from "red" light to "green" light

Access to item structure of push button
$5000+TGROUP_USE_FOUND_ITEM_INDEX, 1160, $36

; Set Trigger Type - ACTION 54
; Exporting: TRIGGER(54:0) for ACTION(1160) {Tomb_NextGeneration}
; <#> : LARA ID 1160 in sector (4,8) of Room2
; <&> : Variables. Set the index of <#>moveable as Selected Item
; (E) :

Also in this case, the index of moveable will be that of push button (the last found item index)
With above trigger we as "Selected Item" the push button, in this way, further trigger to manage Item memory (the fields of some item structure) will work on the structure of push button

Get the index of linked door to open
Copy ocb value to Current value variable: $2000, 256, $11FF

; Set Trigger Type - FLIPEFFECT 256
; Exporting: TRIGGER(4607:0) for FLIPEFFECT(256) {Tomb_NextGeneration}
; <#> : Variables. Memory. Copy to <&> Numeric Variable the (E)Selected Item Memory
; <&> : Current Value
; (E) : OCB Code (The value you typed in OCB of this item) (Short)

Convert ngle item to real tomb item index: $2000, 301, $3

; Set Trigger Type - FLIPEFFECT 301
; Exporting: TRIGGER(3:0) for FLIPEFFECT(301) {Tomb_NextGeneration}
; <#> : Variables. Convert the NGLE Item Index to Tomb Item Index in CurrentValue
; <&> : Current Value

Copy the "Current Value" to "Found Item Index" inventory variable: $2000, 245, $FF

; Set Trigger Type - FLIPEFFECT 245
; Exporting: TRIGGER(255:0) for FLIPEFFECT(245) {Tomb_NextGeneration}
; <#> : Variables. Memory. Copy from <&>Numeric Variable to (E)Savegame Memory
; <&> : Current Value
; (E) : TRNG Index. Index of last item found with testposition or condition (Short)

From now, everytime we perform an exported trigger with TGROUP_USE_FOUND_ITEM_INDEX flag, it will be this index (that we got from ocb of push button, that is the index of door to open, to be used
So now just perform an action trigger to open the door: $5000+TGROUP_USE_FOUND_ITEM_INDEX, 224, $11A

; Set Trigger Type - ACTION 26
; Exporting: TRIGGER(282:0) for ACTION(224) {Tomb_NextGeneration}
; <#> : DOOR_TYPE2 ID 224 in sector (1,1) of Room183
; <&> : Trigger. (Door) (E)Open/Close <#>door
; (E) : Open the door


Simplified scripting to open a door with push button

Previous Advanced scripting for many doors/buttons script was a bit complicated becuase it had to extract the index of door to open from ocb of push button but, if you don't need to have two or more push buttons/doors, the script could become very easy.
Just simply creating a trigger group with two exported triggers:

Trigger to perform animation 1 for push button

; Set Trigger Type - ACTION 15
; Exporting: TRIGGER(271:0) for ACTION(89) {Tomb_NextGeneration}
; <#> : ANIMATING1 ID 89 in sector (3,1) of Room182
; <&> : Force (E) animation (0-31) for <#>object
; (E) : 1 Animation
; Values to add in script command: $5000, 89, $10F


Trigger to open door

; Set Trigger Type - ACTION 26
; Exporting: TRIGGER(282:0) for ACTION(224) {Tomb_NextGeneration}
; <#> : DOOR_TYPE2 ID 224 in sector (1,1) of Room183
; <&> : Trigger. (Door) (E)Open/Close <#>door
; (E) : Open the door
; Values to add in script command: $5000, 224, $11A


Final triggerGroup (simplified version)
So, the TriggerGroup will be this:

TriggerGroup=          2, $5000, 89, $10F, $5000, 224, $11A

It's very easy but has the limitation that it will work only for specific door and pushbutton.
Note: in this simplified version, it's not necessary type some value in OCB of push button, of course